FHIR vs HL7: Differences and How to Choose the Right Healthcare Standard

For many years, the lack of a health data exchange process resulted in poor care coordination and patient performance. Now, we have revolutionary standards that allow better patient care, reduce the cost of care, improve healthcare efficiency, and exchange health data securely. 

HL7 standards and FHIR are widely used within global healthcare. So it’s no wonder the FHIR vs HL7 topic is popular.

Edenlab has a proven track record of the FHIR standard implementation cases for seamless data exchange and ultimate interoperability.

Today, we will discuss the most transformative healthcare standards and define what is the difference between HL7 and FHIR. The development of health data standards has led the world to an understanding of health data accessibility and exchangeability significance and allowed us to build a modern healthcare ecosystem based on interoperability principles. 

What Is HL7?

Health Level 7 International is a not-for-profit ANSI-accredited standards-developing organization. Its goal is to develop standards and provide a framework for exchanging, integrating, and retrieving health data that supports clinical data practices and management, delivery, and evaluation of health services. 

HL7 (Health Level Seven) is the organization that created HL7 V2, HL7 V3, CDA, the HL7 FHIR standard, etc. Most of the standards are widely used around the world today. These standards define rules for communication between various health systems.

The newer standard of HL7 targets implementers, not clinicians. Such an approach considerably simplifies implementation and stimulates developers to create new healthcare IT solutions.

What Is FHIR?

FHIR is the standard developed by Health Level Seven International, as well as other standards whose names start with HL7. FHIR is an innovative healthcare standard that summarizes strong points, fills gaps in previous HL7 standards, and employs existing web technologies that simplify its implementation.

The critical difference between FHIR and HL7’s other standards is that FHIR speeds up and simplifies the development of IT solutions that address healthcare interoperability challenges. This standard is a collection of specifications that define its elements and data formats. Check out our Ultimate Guide – What is FHIR.

HL7 (V2, V3, and CDA) and FHIR. What Are the Differences?

V2 is a legacy system that defines messaging only. The standard doesn’t cover data storage and interoperability problems. The V2 message has an outdated design that does not help the scalability and is impossible to read for non-V2 experts. 

V3 is HL7’s attempt to build an electronic healthcare model with rigid types and XML-based messaging. The HL7 V3 introduces the concept of RIM (Reference Information Model), which represents a static model of healthcare information. It provides messages, terminologies, and data types. 

FHIR is the implementers-focused standard that relies on the open-source paradigm. It is published on the page https://hl7.org/fhir/. Unlike previous healthcare standards, it is available for study and use. Accessibility of the standard greatly contributes to the community interest and involves developers in standard development and testing.

We’ve compiled brief descriptions of the critical characteristics of all standards released by the HL7 organization for achieving interoperability to clarify the difference between FHIR vs HL7 standards.

There’s no universal choice between FHIR and other HL7 standards, but there are several aspects to consider before adopting any of the healthcare data standards by HL7. In short, base your decision on your organization’s unique requirements, existing infrastructure, and long-term goals. Let’s get to the detailed characteristics and message examples of V2, V3, CDA, and FHIR.

HL7 V2 vs FHIR

Health Level Seven Version 2 (V2) is a messaging standard that allows communication between various systems within a hospital. HL7 developed this standard back in 1989 to ensure enterprise-level interoperability in healthcare. It is the world’s most widely implemented healthcare standard—95% of US healthcare organizations use HL7 V2.x.

Technical characteristics

Use cases: HL7 V2 messages allow data transmission between systems (e.g., admit discharge transfer patients, medical prescriptions, financial transactions, observation results, measurement results). 

Let’s look at the HL7 ORU (Observation Result) message. Clinical system A sends the Observation Result message in response to a request created in clinical system A. ORU messages include the following types of observations: lab results, EKG results, study reports, symptoms, allergies, etc. 

Message Structure: HL7 V2 message consists of texts, pipes, and hats.

MSH|^~\&|MESA_RPT_MGR|EAST_RADIOLOGY|iFW|XYZ|||ORU^R01|MESA3b|P|2.4||||||||
PID|||CR3^^^ADT1||CRTHREE^PAUL|||||||||||||PatientAcct||||||||||||
PV1||1|CE||||12345^SMITH^BARON^H|||||||||||
OBR|||||||20010501141500.0000||||||||||||||||||F||||||||||||||||||
OBX|1|HD|SR Instance UID||1.113654.1.2001.30.2.1||||||F||||||
OBX|2|TX|SR Text||Radiology Report History Cough Findings PA evaluation of the chest demonstrates the lungs to be expanded and clear. Conclusions Normal PA chest x-ray.||||||F||||||
CTI|study1|^1|^10_EP1

The HL7 V2 message includes the following segments:

• The Message Header (MSH) – a required segment that cannot be excluded. It consists of data about the message sender and recipient.
• The Patient Identification (PID) – segment includes demographic data of a specific patient (identifier, name, date of birth). PID segment is required. 
• Patient Visit (PV1) – a required message segment with patient visit details (visit ID, caregiver, servicing facility).
• The Observation Request (OBR) – a required segment that allows the identification of the observation ordered for Observation Result message generation. 
• The Observation Result (OBX) – an optional segment that includes information about the observation result. This segment identifies the type of observation, its result, the date of observation, and observation-related information. The segment can be repeated.
• Clinical Trial Identification (CTI) – this segment links the result to a clinical trial. This segment is optional and can be repeated. The segments contain the clinical trial identification information, phase, and time point of the study. 

The HL7 V2 standard is suitable for communication between government healthcare systems with no option to store data in databases. This type of messaging works for data transmission between medical systems in one organization and cannot scale across different organizations.

HL7 V3

In the early 2000s, the recognition of data importance in the context of healthcare workflows became obvious and pushed HL7 to develop a more comprehensive messaging standard. 

As a result, they introduced the Health Level Seven Version 3 (V3) standard, which represents all the data needed for healthcare interoperability. This standard is based on a common Reference Information Model (RIM), which constitutes a universal reference model for all information that needs representation within healthcare.

Reference Information Model example

All RIMs implementation is obligatory for all users of the third version of HL7, which makes the implementation process too complex and costly.

Technical characteristics

Use cases: The HL7 V3 standard was developed in response to data exchange gaps that could not be fixed with HL7 V2. This standard was meant to cover the same use cases as the previous HL7 standard and address communication issues within healthcare.

Message example:

<observationEvent>
   <id root="2.16.840.1.113883.19.1122.4" extension="1045813"
       assigningAuthorityName="GHH LAB Filler Orders"/>
   <code code="1554-5" codeSystemName="LN"
         codeSystem="2.16.840.1.113883.6.1"
         displayName="GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN"/>
   <statusCode code="completed"/>
   <effectiveTime value="200202150730"/>
   <priorityCode code="R"/>
   <confidentialityCode code="N" 
      codeSystem="2.16.840.1.113883.5.25"/>
   <value xsi:type="PQ" value="182" unit="mg/dL"/>
   <interpretationCode code="H"/>
   <referenceRange>
      <interpretationRange>
          <value xsi:type="IVL_PQ">
          <low value="70" unit="mg/dL"/>
          <high value="105" unit="mg/dL"/>
        </value>
        <interpretationCode code="N"/>
      </interpretationRange>
   </referenceRange>

The HL7 V3 message consists of three layers: 

• Transport Wrapper – this level contains all the message transport information, such as the data about the sender and receiver and systems interaction ID message.
• Event Wrapper – contains information about the event, defines its type, trigger, responsive parties, and the date on which the event occurred.  
• Domain Payload – the core layer of the V3 message that includes the administrative and clinical data.

Thanks to the RIM, the third version of the standard covers every possible healthcare use case imaginable, which made the V3 an unbearably complex and cost-prohibitive standard with a big learning curve.

HL7 CDA vs FHIR

 CDA (Clinical Document Architecture) is a flavor of HL7 V3. CDA is a document markup standard that defines the structure of clinical documents to establish the exchange of clinical data between patients and caregivers. CDA defines the following characteristics for all clinical documents: 1) Persistence, 2) Stewardship, 3) Potential for authentication, 4) Context, 5) Wholeness, and 6) Human readability.

Technical characteristics

Use Cases: The Clinical Document Architecture is used to exchange data about the patient. A typical CDA includes text, images, sounds, and other content. CDAs are widely used across healthcare within hospitals, immunization clinics, and other types of healthcare organizations.

Message example:

<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3" xmlns:cda="urn:hl7-org:v3" xmlns:sdtc="urn:hl7-org:sdtc">
	<!-- ** CDA Header ** -->
	<realmCode code="US"/>
	<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
	<!-- US General Header Template -->
	<templateId root="2.16.840.1.113883.10.20.22.1.1" extension="2014-06-09"/>
	<!-- *** Note: The next templateId, code and title will differ depending on what type of document is being sent. *** -->
	<templateId root="2.16.840.1.113883.10.20.22.1.8" extension="2014-06-09"/>
	<id extension="TT988" root="2.16.840.1.113883.19.5.99999.1"/>
	<code codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" code="18842-5" displayName="Discharge summarization note"/>
	<title>Community Health and Hospitals: Discharge Summary</title>
	<effectiveTime value="201409171904-0500"/>
	<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
	<languageCode code="en-US"/>
	<setId extension="sTT988" root="2.16.840.1.113883.19.5.99999.19"/>
	<versionNumber value="1"/>

The full-size example is available in the CDA examples repository on GitHub.

CDA Document Structure:

• Header – includes metadata and sets the context for the document. The information in the header covers the CDA creation date, its creator, organization, and the related patient.
• Body – contains human-readable and machine-readable content for the document in non-XML format. The body represents the authenticated clinical report.  
• Section(s) – a combination of one narrative block and zero-to-many entries. 
• Narrative Block(s) – a text section representing the content for viewing.
• Entries – discrete data for machine processing. 

CDA includes all the patient-related information, including medical history, medications, insurance, lab results, and more. A clinical document includes detailed information about a patient that healthcare providers can freely exchange.

HL7 FHIR

FHIR profiles are a key feature of the FHIR standard, allowing for the creation of specialized data definitions and constraints to support specific use cases and interoperability requirements within the healthcare industry.FHIR is based on HTTP protocol and supports the RESTful API approach. So, what is the FHIR standard? REST is a widely used exchange standard that defines a set of operations within an application programming interface, such as create, read, update, delete, and more. REST APIs simplify data migration between servers and separate clients from a server. That improves the scalability of a FHIR data model. The FHIR standard enables the development of tools for fast access and exchange of EHRs data.

Technical characteristics

Use cases:

An FHIR resource or a combination of resources can cover the most common use cases within healthcare. FHIR provides a seamless exchange of lab test results, clinical letters, scans, and other documents that affect the patient’s outcome.

FHIR functionality is based on REST API, which defines a set of operations on a resource. CRUD operations are the most commonly used for interaction with an FHIR resource within an FHIR server.

Let’s take a look at the structure of the FHIR Diagnostic report resource. A report usually includes the actual text report, images, and codes. The Diagnostic report resource allows laboratory reports (e.g., clinical chemistry), imaging and radiology (x-ray, CT, MRI), pathology, gastroenterology reports, and other diagnostics. 

In the case of lab test results, the resource allows sharing information about a laboratory test and the specimen. You can find more information on messaging using FHIR Resources at hl7.org/fhir to compare FHIR to HL7 V2 messages. 

Message example:

{
  "resourceType" : "DiagnosticReport",
  "id" : "ultrasound",
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2><span title=\"Codes: {http://snomed.info/sct 45036003}\">Abdominal Ultrasound</span> (<span title=\"Codes: {http://snomed.info/sct 394914008}, {http://terminology.hl7.org/CodeSystem/v2-0074 RAD}\">Radiology</span>) </h2><table class=\"grid\"><tr><td>Subject</td><td><b>Jim </b> male, DoB: 1974-12-25 ( Medical record number: 12345 (use: USUAL, period: 2001-05-06 --&gt; (ongoing)))</td></tr><tr><td>When For</td><td>2012-12-01T12:00:00+01:00</td></tr><tr><td>Reported</td><td>2012-12-01T12:00:00+01:00</td></tr></table><p><b>Report Details</b></p><p>Unremarkable study</p></div>"
  },
  "status" : "final",
  "category" : [{
    "coding" : [{
      "system" : "http://snomed.info/sct",
      "code" : "394914008",
      "display" : "Radiology"
    },
    {
      "system" : "http://terminology.hl7.org/CodeSystem/v2-0074",
      "code" : "RAD"
    }]
  }],
  "code" : {
    "coding" : [{
      "system" : "http://snomed.info/sct",
      "code" : "45036003",
      "display" : "Ultrasonography of abdomen"
    }],
    "text" : "Abdominal Ultrasound"
  },
  "subject" : {
    "reference" : "Patient/example"
  },
  "effectiveDateTime" : "2012-12-01T12:00:00+01:00",
  "issued" : "2012-12-01T12:00:00+01:00",
  "performer" : [{
    "reference" : "Practitioner/example"
  }],
  "media" : [{
    "comment" : "A comment about the image",
    "link" : {
      "reference" : "DocumentReference/1.2.840.11361907579238403408700.3.1.04.19970327150033",      "display" : "WADO example image"
    }
  }],
  "conclusion" : "Unremarkable study"
}

A resource consists of four parts:

• Metadata – contains the resource details (date of the resource creation, resource version ID)
• Narrative – the HTML representation of the resource’s content; the human-readable summary. 
• Extensions – the part of a resource used to add data that initially is not a part of a defined resource structure.
• Standard data – the block includes the medical record number, patient name, gender, birth date, info about the care provider, etc.

As you can see, an FHIR resource has a user-friendly structure. HL7 V2 vs FHIR is limited to exchange of data between systems within one entity, and HL7 V3 vs FHIR has a less flexible information model making the standard too complex for implantation. 

The FHIR standard leverages existing web technologies, encouraging developers to create new healthcare IT solutions. All the data, including coded elements, are represented in human-readable form.

What Are the Similarities Between HL7 and FHIR?

HL7 and FHIR standards are parts of one family of standards. HL7 and FHIR protocols vary since FHIR sticks to commonly used web technologies and protocols. However, FHIR includes all the best features and practices of previous HL7 standards. 

For example, CDA and HL7 V3 both are based on RIM, and FHIR includes many components of CDA that are used for exchanging information about the patient. 

The FHIR interoperability standard brings the concept of resources as the smallest exchange unit within healthcare, which becomes a solution to clinical and administrative issues. Resources can be extended to fit a specific use case, making the FHIR standard way more flexible in comparison to HL7 V2, V3, and CDA.

Pros and Cons of HL7 and FHIR?

FHIR is a part of the HL7’s family of healthcare standards, which is the best choice for ensuring interoperability in healthcare. However, implementation of the standards has its pros and cons that should be noted by healthcare stakeholders:

Pros:

• Wide Adoption: all HL7 standards, including FHIR, are globally recognized and ensure consistent data exchange.
• Backward Compatible: FHIR, compared to some previous standards by HL7, prioritizes backward compatibility, easing communication between older and newer systems.
• Specific Messaging: Tailored messaging solutions for various healthcare scenarios support standardized data exchange.

Cons:

• Legacy System Compatibility: Some legacy healthcare systems may not support FHIR, requiring hard work to ensure semantic interoperability in healthcare. 
• Learning Curve: Despite accessibility, professionals may need time to learn these standards for effective implementation.
• Data Security: When implementing any healthcare standards, complying with data privacy regulations is a must to avoid catastrophic consequences of healthcare data breaches.

In summary, FHIR, among HL7 standards, excels in achieving semantic interoperability in healthcare. The choice between different HL7 standards should align with an organization’s needs.

Transitioning from HL7 to FHIR

Migrating proprietary formats to newer standards can help achieve interoperability and regulatory compliance in healthcare. However, switching between standards requires a well-thought-out approach to effectively leverage modern health data management standards.

Challenges in Migration

• Compatibility: Ensuring seamless conversion between formats.
• Mapping Complexity: Addressing complex mapping rules.
• Integration: Integrating with existing systems.
• Data Validation: Ensuring data accuracy.
• Compliance and Security: Meeting regulatory standards.

Best Practices for Migration

• Compatibility: The Kodjin FHIR Data Mapper, designed to convert proprietary and custom formats to FHIR, allows for predefined templates that dictate mapping rules for transforming data elements from various formats into FHIR bundles.

• Mapping Complexity: Templates within the Mapper can be tailored to intricate mapping requirements, thus refining the conversion process, ensuring alignment with FHIR standards, and handling diverse data structures efficiently.

• Integration: Integration with existing systems is achieved by fetching appropriate templates based on the data’s format and processing the data according to the mapping rules within the template. This ensures seamless data exchange between different systems while maintaining compatibility and consistency.

• Data Validation: Besides predefined templates and custom filters for refining the conversion process to meet FHIR, the custom ETL/ELT process setup allows Kodjin Mapper for specialized data transformation logic tailored to unique healthcare data needs, enhancing data accuracy and integrity.

• Compliance and Security: Mapper and all the other solutions in the Kodjin Interoperability Suit are designed to meet regulatory standards, including compliance with HIPAA and other healthcare regulations. 

Get started with FHIR with Kodjin

Through the deployment of an FHIR-compliant solution with a custom clinical data mapper for Elation Health, Edenlab successfully overcame the challenges of transforming large volumes of EHR data into the FHIR format, ensuring seamless data exchange, interoperability, and compliance with regulatory standards.

Read also: EHR interoperability: Importance, Issues, and Solutions

Use case highlights:

• Regulatory Compliance: Achieved ONC certification by ensuring compliance with USCORE 3.1.1 standards;

• USCORE 5.0.1 Support: Implemented USCORE 5.0.1 compatibility, future-proofing the client’s solution against updates in regulatory requirements;

• High Performance: The optimized system achieved a peak performance of 1160 Requests per Second (RPS), significantly improving operational efficiency and data accessibility.

• SMART on FHIR Functionality: Providing secure authorization and authentication for clinicians by integrating SMART on FHIR functionality;

Customizable ETL Mapping Templates: Established ETL mapping to FHIR to enable the system to adapt to specific requirements and ensure flexibility.

Summary

We tried to demystify the false ideas about HL7 and FHIR and define the main difference between HL7 vs FHIR. Here at Edenlab, the creators of the Kodjin Interoperability Suite, we focus on interoperability challenges. For more than seven years, we’ve been helping our customers solve healthcare data management issues.

Contact us if you want to know how to apply healthcare standards for your project. Our team will be pleased to meet your needs.

FAQ

Why is FHIR better than HL7?

When choosing between FHIR integration or HL7, remember, there is no right or wrong choice between HL7 and FHIR. FHIR is a standard developed as HL7, as well as HL7 V2, V3, and other standards. FHIR is the newest standard that addresses healthcare interoperability problems, whereas HL7 V2 is used for communication within different systems in a healthcare establishment. Adopting FHIR is necessary for providers who want to comply with industry standards. 

How is FHIR different from HL7?

The main difference between FHIR and HL7’s previous standards is the fast and simple implementation of FHIR resources compared to leveraging older standards and RESTful architecture support.

Why Is FHIR More Powerful Than HL7?

One reason FHIR is more powerful lies in the HL7 vs. FHIR format difference. The older HL7 standards support XML; the HL7 V2 format is based on pipe and hat encoding. 

FHIR leverages modern web technologies, such as RESTful APIs, XML, and JSON. Widely-used open technologies enable more developers to create new healthcare IT solutions. 

Post author

Sveta Vedmed

Business Analyst at Edenlab